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Application No. 09/842,801 

Reply to Office Action of April 20, 2005 



O) REAL PARTY IN INTEREST 

The real party in interest in the present appeal is AIRSYS ATM S.A. having a place 

of business at 19, rue de la Fontaine, 92220 Bagneux, France. 



OP RELATED APPEALS AND INTERFERENCES 

Appellant, Appellant's legal representatives, and assignee are not aware of any other 
appeals, interferences, or judicial proceedings that will directly effect or be directly affected 
by or have a bearing on the board's decision in the pending appeal. 



(Ill) STATUS OF CLAIMS 

Claims 17-42 are pending in this application and are being appealed. Clean copies of 
the appealed claims appear in the (viii) claims appendix. 

(IV) STATEMENT OF AMENDMENTS 

A Request for Reconsideration under 37 C.F.R. §1.116 was filed on July 20, 2005 in 
response to the Final rejection of April 20, 2005. In reply, an Advisory Action was mailed on 
August 8, 2005, indicating that, Appellants' reply does not place the application in condition 
for allowance and is not considered persuasive and, for purposes of Appeal, would be 
entered. 
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(V) SUMMARY OF CLAIMED SUBJECT MATTER 

In data routing systems where the operational reliability is important, redundancy of 
data routers is desired. Conventional solutions for data routing systems propose multiple 
routers that are linked together by an arbitration system to hand-over from one router to 
another, if one router is defective. Appellant of the present invention have recognized that to 
reduce the costs associated with operational reliability, a third-party arbitration system can be 
eliminated, thereby not degrading operation reliability, whatever types of input/output ports 
are used. 

As shown as a non-limiting illustration of the instant invention in Figures 1 and 2 of 
Appellant's specification, the invention recited in independent Claim 17 is directed to a 
redundant routing system. Independent Claim 39 recites similar features in means-plus- 
function language. The redundant routing system includes: a first routing unit 1 (Claim 39: 
first routing means) 1 configured to manage input and output data; a second routing unit 2 
(Claim 39: second routing means) 2 configured to manage input and output data; a network 
interface 23 (Claim 39: networking means) 3 connecting the first and second routing units; and 
a standby bus interface 6, 24 (Claim 39: connecting means) 4 connecting the first and second 
routing units to each other; wherein, when the first routing unit is managing the input and 
output data, the second routing unit is configured to detect a failure (Claim 39: failure 
detecting means) 5 of the first routing unit by monitoring both the network 23 and standby bus 
interfaces 6, 24. Furthermore, when the second routing unit 2 detects a failure of the first 
routing unit 1, the second routing unit 2 is configured to deactivate (Claim 39: resetting 
means) 6 the first routing unit 1 so that the first routing unit 1 no longer manages the input and 

1 See Applicant's specification, for example at page 4 S lines 26-27. 

2 Idem at page 4, line 27. 

3 Idem at page 5, lines 26-28 and at page 6, lines 4-5. 

4 Idem at page 5, lines 21-24 and at page 6, lines 18-23. 

5 Idem at page 6, lines 30-33 

6 Idem at page 7, lines 14-32. 
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output data and the second routing unit 2 is further configured to start managing the input and 
output data. Claim 40 depends upon Claim 39 and recites linking means 7 for connecting said 
first and second routing means to at least one other system. Claim 42 depends upon Claim 39 
and recites polling means 8 for exchanging polling messages via said networking and 
connecting means, said polling messages carrying information relevant to detecting said 
failure. 

(VI) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

The grounds for rejection to be reviewed on appeal and outstanding in the present 
application are as follows: 

Claims 17-42 were rejected under 35 U.S.C. § 102(e) as anticipated by Kanekar et aL 
(U.S. Patent No. 6,751,191, herein " Kanekar "). 

CVm ARGUMENT 

Appellant respectfully requests that the Board reverse the Examiner's rejection of 
Claims 17-42 because Kanekar fails to teach or suggest all the elements of Appellant's 
independent Claims 17 and 39, as next discussed. 

The applied reference Kanekar discloses a load sharing redundancy scheme, wherein 
with a first and second router have a shared set of interfaces, enabling the first router and the 
second router to share forwarding data for forwarding packets on the shared set of interface. 9 
However, Kanekar fails to teach or suggest a standby bus interface 6 connecting the first 
and second routing units to each other. The final Office Action of April 20, 2005 asserts 

7 Idem from page 4, line 29 to page 5, line 3 and at page 6, lines 5-10. 

8 Idem at page 6, lines 15-25. 

9 See Kanekar in the Abstract. 
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that Kanekar teaches "a standby bus interface connecting the first and second routing units to 
each other" based on the line between items 914 and 916 of Kanekar' s Figure 9. 10 Appellant 
respectfully disagrees and submits that (1) the cited line connects the forwarding engines 914 
and 916, and not the routing units, to each other and (2) there is no teaching or suggestion in 
Kanekar that the line in question is a standby bus interface. Further, the Advisory Action of 
August 8, 2005 states that Kanekar discloses in Figure 9 a standby bus interface. Again, 
Appellant respectfully disagrees. Figure 9 merely shows a dotted arrow pointing from router 
Rl to router R2, and recites that "where the first router 902 is the master and the second 
router 904 is the slave, the master sends information ... to the slave, as shown at line 930. " ll 
The mere indication by an arrow that information is sent from the master to the slave does not 
mean that there is a standby bus interface connecting the first and second routing unit to each 
other, as claimed. Kanekar further teaches that "the slave operates in standby mode and 
therefore obtains information by observing packets as they are received at the interfaces 
shared with the master." 12 The shared interfaces, however, are shown in Figure 3 and are the 
interfaces with the numerals 206-1, 206-2 and 206-3 13 and are part of the network interface to 
the client 210. Accordingly, Kanekar does not have a standby bus interface connecting said 
first and second routing units to each other. 

Further, Appellant respectfully submits that Kanekar fails to teach or suggest that the 
first routing unit is managing the input and output data, the second routing unit is configured 
to detect a failure of the first routing unit by monitoring both the network and standby bus 
interfaces, as recited in independent Claim 17. The Advisory Action of August 8, 2005 states 
that Kanekar discloses such a feature and points out to column 12, lines 4-22 of Kanekar . 
Since there is no standby interface in Kanekar , as argued above, it is not possible that the 

10 See the April 20, 2005 Office Action at page 3, lines 9-10. 

11 See Kanekar at column 20, lines 26-29 and in corresponding Figure 9. 

12 See Kanekar at column 7, lines 50-54 and in corresponding Figure 5. 

13 See Kanekar at column 6, lines 4-12 and in Figure 3. 
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network and the standby bus interface are monitored. The Office Action of April 20, 2005 
asserts that Kanekar teaches the above feature at column 14, lines 14-29. 14 Appellant 
respectfully disagrees, since Kanekar states that "a failure of one of the routers is detected by 
another router when a specified number of consecutive 'hello 5 packets are not received 
during a period of time. Since the routers communicate in the backplane of the device, a 
failure of one of the routers may be detected in hardware." 15 Therefore, Kanekar " s routers 
only communicate with respect to the failure determination "in the backplane of the device" 
and Kanekar also states that "the slave and the master share the same set of interfaces, the 
slave may observe incoming and outcoming packets." Accordingly, the second routing unit 
is not configured "to detect a failure of the first routing unit by monitoring both said network 
and standby bus interfaces" (emphasis added). 16 

Further, Appellant respectfully submits that Kanekar fails to teach or suggest that the 
second routing unit is configured to deactivate the first routing unit so that the first routing 
unit no longer manages the input and output data and the second routing unit is further 
configured to start managing the input and output data, as claimed. The final Office Action 
of April 20, 2005 asserts that Kanekar teaches such a feature at column 14, lines 14-29. 
Appellant respectfully disagrees and submits that Kanekar states in this passages that "once 
the master fails, the slave actively forwards packets and monitors all traffic coming into the 
switch." Actively forwarding packets by the slave, once the master fails, as taught by 
Kanekar . is not a slave deactivating the master, as claimed. Further support against the above 
allegations of the April 20, 2005 Office Action is found in Kanekar which states that "the 
master runs the layer 2 spanning tree protocol until the master fails, at which time the slave 



14 See the April 20, 2005 Office Action at page 3, lines 1 1-13. 

15 See Kanekar, column 7, lines 25-30. 

16 See Kanekar at column 14, lines 17-20. 

17 See the April 20, 2005 Office Action at page 14-17. 
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starts running the layer 2 spanning tree protocol." 18 Absent such a specific teaching or 
suggestion, and particularly in light of Kanekar ' s Figures 12A-12D which do not disclose any 
operation of the slave onto the master except in contextually unrelated Figure 1 2B directed to 
a failing slave, one of ordinary skill in the art would interpret Kanekar as teaching that the 
slave detects the failure of the master and takes over, while the master either remains in its 
failure state, not necessarily deactivated, or perhaps deactivated by its own failure, but never 
deactivated by the slave. The Advisory Action of August 8, 2005 states that "the routing 
processor of the slave sends a signal to the forwarding engine to replace the references to the 
MAC address and IP address of the master with the MAC address and IP address of the slave, 
where appropriate." 19 In other words, at the forwarding engine, the address of the master is 
changed to the address of the slave and the master router is not deactivated. Accordingly, 
exchanging an address at a forwarding engine 514 of a router 502, as taught by Kanekar, is 
not deactivating a first routing unit so that said first routing unit no longer manages said input 
and output data, as claimed. 

Independent Claim 39 recites features similar to those of independent Claim 17, in 
means-plus-function language. It is thus respectfully submitted that the above arguments also 
apply to independent Claim 39. 

In conclusion, Appellant respectfully requests that the Board reverse the rejection of 
Claims 17-42, since the applied reference Kanekar fails to teach or suggest every feature 
recited in Appellant's independent Claims 17 and 39. In view of the foregoing remarks, 
Appellant respectfully request that the rejection under 35 U.S.C. § 102(e) over Kanekar be 
reversed. 

Furthermore, Appellant respectfully requests that the Board reverse the rejection of 
the dependent claims at least for the reasons stated above regarding independent Claims 1 7 

18 See Kanekar , column 7, lines 43-46. 

19 See the August 8, 2005 Advisory Action citing Kanekar at column 12, lines 11-15. 
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and 39 and respectfully submits that the applied reference Kanekar is silent on features of the 
dependent claims. Appellant respectfully disagrees with several assertions in the Office 
Action of April 20, 2005 and the Advisory Action of August 8, 2005 regarding the rejection 
of the dependent claims, as next discussed. 

Regarding dependent Claim 18, Appellant respectfully submits that Kanekar fails to 
teach or suggest that the first and second routing units have identical functions and include 
identical software and configuration files. The final Office Action of April 20, 2005 rejects 
Claim 18 based on Kanekar 9 s teachings at column 4, lines 25-27, and column 6, lines 40-61. 
Further, the Advisory Action of August 8, 2005 states that Kanekar teaches that the master 
and slave have identical spanning tree databases and identical configurations. 20 Appellant 
respectfully disagrees with both the final Office Action and the Advisory Action. Kanekar 
does not teach or suggest that the configuration of the master and the slave are identical. 
Kanekar merely states at column 6 that some "configurations that can be different."' 1 In 
addition, Kanekar explicitly lists the configurations that have to be identical: number of ports 
in each line card, the type of ports and the security information. 22 Accordingly, the cited 
passages may support the teaching of identical configuration files, but clearly fail to teach or 
suggest identical software and configuration files, as claimed by Appellant. Different 
software could use identical configuration files, and software can sometimes run without 
configuration files, so that a teaching of identical configuration files does not meet one of 
identical software and configuration files. 

Regarding dependent Claim 19, the final Office Action of April 20, 2005 further 
asserts that Kanekar teaches or suggest the features of dependent Claim 19, to recite "at least 
one serial link connecting said first and second routing units to at least one other system," 

20 See Kanekar at column 7, lines 62-63 and at column 6, lines 

21 See Kanekar at column 6, lines 55-61. 

22 See Kanekar at column 6, lines 47-5 1 . 
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based on Kanekar' s Figures 1 and 5. The Advisory Action of August 8, 2005 is silent 
regarding the teachings of Appellant's Claim 19. Appellant respectfully disagrees with the 
April 20, 2005 Office Action and submits that Kanekar ' s Figure 1 shows elements 1 12, 116, 
118, and 120 connected in series via network segments 114. However, the network segments 
are not actually "serial links" even if the general arrangement of Figure 1 can be colloquially 
described as serial. One can connect nodes "serially" using a variety of types of inter-node 
links, but Kanekar does not teach or suggest the use of what is well understood in the art as a 
"serial link." To that effect, Appellant's specification mentions in a non-limiting passage 
"[sjtandard serial links, using protocols such as X25, HDLC and BSC for example." 
Appellant respectfully points out that in view of Appellant's specification, a person of 
ordinary skill in the art would not see "serial links" in Kanekar ' s Figure 1 . Further, 
Kanekar ' s Figure 5 discloses a connection to VLANs, but Kanekar does not teach or suggest 
that this connection would use serial links. 

Regarding dependent Claim 20, the final Office Action of April 20, 2005 also asserts 
at page 4 that Kanekar teaches the "at least one serial link comprises at least one Y-split 
cable" feature of Claim 20 based on Figure 15 and column 17, lines 36-56. Again Appellant 
respectfully disagrees and submits that (1) Kanekar does not teach or suggest serial links, as 
argued above, and (2) the cited line between elements 1468 and 1415, whatever type of 
connection it may corresponds to, is straight and not Y-split. Further, the cited passage 
mentions a number of connections, including Ethernet, ATM, HSSI, POS, FDDI, none of 
which relate, or are asserted to relate, to a Y-split cable. 

Regarding dependent Claims 22-23, the final Office Action of April 20, 2005 further 
asserts at page 4 that Kanekar teaches the "said first routing unit deactivates itself and 
activates said second routing unit by a change in an impedance of at least one input/output 

23 See Appellant's Specification, for example at page 1, lines 28-29. 
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serial port" feature of Claim 22 based on Figures 12 and 14, and from column 11, line 55 to 
column 12, line 55. In particular, the Office Action identifies the "back plane signal" as 
analogous to the claimed change in an impedance. Appellant respectfully disagrees and 
submits that Kanekar states that "a failure of one of the routers is detected by another router 
when a specified number of consecutive 'hello' packets are not received during a period of 
time. Since the routers communicate in the backplane of the device, a failure of one of the 
routers may be detected in hardware" 24 so that the backplane signal carries 'hello' packets 
and does not operate by any change in impedance. Along the same lines, whereas a port may 
be blocked in Kanekar , as stated in the Office Action at page 5 regarding Claim dependent 
23, the cited blockage does not relate to a role in the transfer between the master and the 
slave, but only to the status of all input-output ports which are synchronized at block 1 102 
(which synchronization occurs prior to any failure). Accordingly, Appellant respectfully 
submits that Kanekar fails to teach or suggest all the features of dependent Claims 22-23. 

Regarding dependent Claim 24, Appellant further respectfully submits that Kanekar is 
silent on the second routing unit deactivates said first routing unit by sending a reset 
command to said first routing unit via the standby bus, said reset command executing a reset 
algorithm on said first routing unit, as recited in dependent Claim 24. The April 20, 2005 
Office Action rejects this claim based on Figures 12 and 14, and from column 11, line 55 to 
column 12, line 55. Appellant respectfully disagrees and submits that (1) Kanekar ' s slave 
does not actually deactivate the master; (2) no reset command is disclosed in the cited figures 
and passage of Kanekar ; and (3) no reset algorithm is executed on Kanekar' s master. The 
Advisory Action states that Claim 24 is anticipated based on Kanekar ' s text at column 12, 
lines 4-22, to recite "the routing processor of the slave sends a signal to the forwarding 
engine to replace the references to the MAC address and IP address of the maser with the 

24 See Kanekar at column 7, lines 25-30. 
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MAC address and IP address of the slave." Again, signaling the forwarding engine to replace 
the address of the master with the addresses of the slave, as taught by Kanekar , is not 
executing a reset algorithm on the first routing unit, and further since Kanekar does not teach 
or suggest a standby bus interface, a reset command cannot be sent to the first routing unit via 
the standby bus. 

Regarding dependent Claim 25, the final Office Action of April 20, 2005 asserts at 
page 5 that Kanekar teaches the features of Claim 25, to recite "wherein polling messages are 
exchanged via said network and standby bus interfaces, said polling messages carrying 
information relevant to detecting said failure," based on Figure 5 and column 7, lines 17-48. 
Appellant respectfully disagrees and submits that Kanekar exchanges "hello" messages in the 
backplane signal, as discussed above, but there is no redundancy, i.e., Kanekar ' s messages 
are not exchanged via both "said network and standby bus interfaces." Further, since 
Kanekar does not disclose a standby bus interface, as argued above, Kanekar cannot teach or 
suggest the feature of dependent Claim 25. 

Regarding dependent Claim 33, the final Office Action of April 20, 2005 further 
asserts at page 6 that Kanekar teaches the "Open Communication Mode (OCM)" feature of 
Claim 33 based on column 17, lines 14-56. Appellant respectfully disagrees and submits that 
the cited passages explicitly mentions numerous modes or protocols, including Internetwork 
Operating System, DSL, ATM, HSSI, POS, and FDDI. However, there is no mention or 
suggestion of OCM, which was specifically claimed. 

Regarding dependent Claim 34, Kanekar fails to teach or suggest the alert protocol to 
warn of a possible failure of dependent Claim 34. The Office Action of April 20, 2005 
asserts at page 6, line 1 8 that Kanekar teaches such a feature and refers to the "back plan 
signal [sic]." Appellant respectfully disagrees and submits that the Office Action already 



11 



Application No. 09/842,801 

Reply to Office Action of April 20, 2005 

resorted to the backplane signal as teaching a change in an impedance. A feature of 
Kanekar, which is already asserted to teach a first feature of Appellant's invention, cannot 
properly meet a second, distinct and additionally claimed feature of Appellant's invention. 
Furthermore, the "backplane signal" 26 of Kanekar, as discussed above, carries "hello" 
messages which indicate a failure "when a specified number of consecutive 'hello' packets 
are not received during a period of time" and not an alert indicating the possibility of a 
failure. 



Used by the final Office Action on page 4, lines 21-22 regarding dependent Claim 22. 
See Kanekar at column 11, line 62. 
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In view of these foregoing comments regarding independent Claims 17 and 39 as well 

as the dependent claims, each of the pending Claims 17-42 clearly distinguish over the 

applied art, and thus the outstanding rejections of Claims 17-42 must be REVERSED. 



Respectfully submitted, 
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(VIII) CLAIMS APPENDIX 

Claim 17: A redundant routing system, comprising: 

a first routing unit configured to manage input and output data; 

a second routing unit configured to manage input and output data; 

a network interface connecting said first and second routing units; 

a standby bus interface connecting said first and second routing units to each other; 

wherein, when said first routing unit is managing said input and output data, said 
second routing unit is configured to detect a failure of said first routing unit by monitoring 
both said network and standby bus interfaces; and 

wherein, when said second routing unit detects a failure of said first routing unit, said 
second routing unit is configured to deactivate said first routing unit so that said first routing 
unit no longer manages said input and output data and said second routing unit is further 
configured to start managing said input and output data. 

Claim 18: The system of claim 17, wherein said first and second routing units have 
identical functions and include identical software and configuration files. 

Claim 19: The system of claim 17, further comprising at least one serial link 
connecting said first and second routing units to at least one other system. 

Claim 20: The system of claim 19, wherein said at least one serial link comprises at 
least one Y-split cable. 

Claim 21: The system of claim 19, wherein, when said first routing unit detects a 
failure in itself, said first routing unit is configured to deactivate itself to cease managing said 
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input and output data and allow said second routing unit to start managing said input and 
output data. 

Claim 22: The system of claim 21, wherein said first routing unit deactivates itself 
and activates said second routing unit by a change in an impedance of at least one 
input/output serial port. 

Claim 23: The system of claim 22, wherein the change in impedance imparts putting 
said at least one input/output serial port in a high impedance state. 

Claim 24: The system of claim 17, wherein said second routing unit deactivates said 
first routing unit by sending a reset command to said first routing unit via the standby bus, 
said reset command executing a reset algorithm on said first routing unit. 

Claim 25: The system of claim 17, wherein polling messages are exchanged via said 
network and standby bus interfaces, said polling messages carrying information relevant to 
detecting said failure. 

Claim 26: The system of claim 25, wherein said second routing unit detects said 
failure of said first routing unit when said polling messages are not properly responded to on 
at least one of said network and standby bus interfaces. 

Claim 27: The system of claim 26, wherein sets of parameters necessary to interpret 
the polling messages, comprising the messages themselves, at least one transmission interval 
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between the messages, and at least one time limit between two messages, are stored in at least 
one configuration file contained in both said first and second routing units. 

Claim 28: The system of claim 27, wherein, when launching an application on said 
first and second routing units, a set of parameters appropriate to said application is loaded 
into a random access memory (RAM). 

Claim 29: The system of claim 17, wherein said network interface links said first and 
second routing units with at least one remote client system. 

Claim 30: The system of claim 17, wherein said network interface is the Internet. 

Claim 31: The system of claim 17, wherein said network interface is an Ethernet 
network. 

Claim 32: The system of claim 17, wherein said network interface is a digital local 
area network (LAN). 

Claim 33: The system of claim 17, wherein said first and second routing units operate 
in Open Communication Processor (OCP) mode. 

Claim 34: The system of claim 17, further comprising an alert protocol to warn of a 
possible failure of the system. 
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Claim 35: The system of claim 17, wherein said first and second routing units are data 

routers. 

Claim 36: The system of claim 17, wherein said first and second routing units are data 

servers. 

Claim 37: The system of claim 18, wherein, after said second routing unit is activated 
and starts managing input and output data, said first routing unit is configured to detect a 
failure of said second routing unit. 

Claim 38: The system of claim 17, wherein, when said first routing unit detects a 
failure in itself, said first routing unit is configured to deactivate itself to cease managing said 
input and output data and allow second routing unit to start managing said input and output 
data. 

Claim 39: A redundant routing system, comprising: 

first routing means for managing input and output data; 

second routing means for managing input and output data; 

networking means for connecting said first and second routing means; 

connecting means for directly connecting said first and second routing means to each 

other; 

failure detection means, wherein, when said first routing means is managing said 
input and output data, said second routing means is configured to detect a failure of said first 
routing means using both said networking and connecting means; and 
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resetting means, wherein, when said second routing means detects a failure of said 

first routing means, said second routing means is configured to deactivate said first routing 

means so that said first routing means no longer manages said input and output data and said 

second routing means is further configured to start managing said input and output data. 

Claim 40: The system of claim 39, further comprising linking means for connecting 
said first and second routing means to at least one other system. 

Claim 41 : The system of claim 39, wherein, when said first routing means detects a 
failure in itself, said first routing means is configured to deactivate itself to cease managing 
said input and output data and allow second routing means to start managing said input and 
output data. 

Claim 42: The system of claim 39, further comprising polling means for exchanging 
polling messages via said networking and connecting means, said polling messages carrying 
information relevant to detecting said failure. 
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(IX) EVIDENCE APPENDIX 



None. 
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(X) RELATED PROCEEDINGS APPENDIX 

None. 
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